rootscan_06_툴 포지셔닝에 대해 생각하기

1. 이미 있는 툴을 뭐하러 다시 만들지?

처음 이 MVP를 만들고 소개했을 때
이미 시장에 SonarQube나 Snyk이라는 거대한 표준이 있는데, 굳이 이걸 만들어야 하냐는 질문을 받았다.
어차피 쓸 사람들은 알아서 Semgrep이나 Trivy를 쓰기도 하고....

2. 보안 도구의 권력 이동

좀 너무 거창하게 들릴 수도 있지만 권력 이동이라는 말을 써본다.

여러 이야기를 들어본 바로는 실무의 보안 도구는 감시자의 도구라고 한다.
보통 조직 단위로 도입되고, 정책이 먼저 정해진다.
보안 팀이나 관리자가 기준을 설정하고, 개발자는 그 결과를 전달받는다.
문제가 있으면 이걸 고쳐야 다음 단계로 갈 수 있다는 식의 흐름이 된다.
Top-down 흐름이라고 봐도 무방하다.

rootscan은 개발자에게 주도권을 주는 도구다.
감시받기 전에, 검사받기 전에 내가 먼저 확인하고 로컬에서 조용히 문제를 해결한다.
보안의 주체가 '관리하는 조직'에서 '코드를 짜는 개인'으로 넘어가는 것이다.
Snyk 등이 개발자 경험을 강조한다고 해도 설계의 중심은 조직 단위의 가시성과 통제에 있으니까.

또 이런 질문이 나올 수 있다.
"어차피 Semgrep나 Trivy나, 써야 하는 도구만 바꾼 거 아닌가? 그냥 wrapper일 뿐 아닌가?"
기술적으로는 맞는 말이다. 잘 만든 엔진을 묶은 것에 불과하니까.

하지만 사용자 경험은 전혀 다르다.
Semgrep이나 Trivy를 직접 쓰는 건 어렵지 않다. 하지만 그걸 항상 같은 시점에, 같은 기준으로, 매번 빠뜨리지 않고 쓰는 건 전혀 다른 문제다. 이미 Semgrep과 Trivy를 매번 로컬에서 같은 기준으로 돌리는 개발자라면 rootscan은 굳이 필요하지 않을 수 있다. 다만 그걸 매번 챙기지 못하는 사람이라면, 한 번쯤 써보라고 권할 수 있을 것이다.

또 rootscan은 엔진이 하지 못하는 부분들, 해석의 빈 틈도 채워줄 수 있다.
엔진이 뱉어낸 로우 데이터(로그)를 '쉽게 읽을 수 있는 정보'로 가공할 수도 있으니까.

3. 불편함을 해소하기

직접 엔진(Semgrep)을 튜닝하고 LLM을 붙여보면서, 단순히 API를 가져다 쓰는 사람은 절대 알 수 없는 "현장의 맥락"을 이해할 수 있었다.

• 왜 개발자들이 보안 알림을 "노이즈"로 취급하는지
• 어디까지 자동화해야 귀찮지 않은지
• 상용 도구가 왜 로컬에서 무거운지

그 이유는 아래와 같았다.

• 알림에 경고가 많아서가 아니라, 지금 봐야 할 것과 아닌 게 섞여 있기 때문이었고
• 자동화가 부족해서가 아니라, 어디까지 자동화해야 하는지 애매하기 때문이고
• 기능이 많아서라기보다는 설계 대상이 다르기 때문이었다

상용 도구는 조직 단위의 관리와 가시성을 전제로 만들어진다.
그 구조에서는 로컬 개발자가 가볍게 쓰기 어려운 게 당연했다.
따라서 그 반대 방향에서 출발했다. 조직을 설득하기 위한 도구가 아니라, 개발자가 혼자 써도 부담 없는 형태 말이다.

결론적으로 '개발자 로컬 경험(Inner Loop)'에 집중하는 상호보완적 도구라고 봐주면 좋겠다.